
Anmeimdme^s to She Specification: 

Please replace the identified paragraphs, with the following new paragraphs: 



On page 9, at line 10, change "324" to -3$4--. 

When the MS 300 leaves the vicinity of the PDSN 304 and enters the vicinity of 
another PDSN 314, the MS 300 sends an origination message. If the MS 300 is 
engaged in a data call, the call is "handed off" from the first PCF/BS 306 to a second 
PCF/BS 316 coupled to the second PDSN 314. An exemplary handoff procedure is 
described in U.S. Patent No. 5,267,261, which is assigned to the assignee of the 
present invention and fully incorporated herein by reference. The MS 300 then sends 
an origination message informing the second PDSN [[324]] 314 of its new location and 
requesting the establishment or reconnection of the PPP instance associated with the 
call. Otherwise, the PPP instances 302, 308 are "dormant" and the MS 300 performs a 
dormant handoff and then sends an origination message that informs the second PDSN 
314 of the new location of the MS 300. It would be understood by those of skill that the 
second PDSN 314 may also be served by more than one PCF/BS 316, but for simplicity 
only one PCF/BS 316 is shown coupled to the PDSN 314. Although the network has 
been informed of the new location of the MS 300, the MS 300 requires that two new 
PPP instances be initiated (because the MS 300 has two dormant SRJDs pertaining to 
the dormant PPP service instances 302, 308). The new PCF/BS 316 and PDSN 306 do 
not have tables listing SRJDs or R-P IDs because the two necessary PPP instances 
have not been established. Accordingly, data packets being sent to the MS 300 will be 
routed to the first PDSN 304 because the MS 300 does not have a PPP instance 
established with the new PDSN 314. Hence, packets destined for the MS 300 will 
become lost. 



Paragraph starting at page 9, line 25, change text on page 10, lines 5, 6 - sets the DRS 
flag is sot _ 




In one embodiment, as shown in FIG. 3B, an MS 318 travels from the vicinity of a 
first PDSN 320 and associated PCF/BS 322 to the vicinity of a second PDSN 324 and 
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associated PCF/BS 326 and informs the second PDSN 324 of the number and identities 
of PPP instances that must be established. The first PDSN 320 had established two 
PPP instances 328, 330 between the PDSN 320 and the PCF/BS 322, which were 
dormant (i.e., not being used to transmit traffic channel data). The various established 
connections and addresses are included in the respective tables 332, 334 for the PDSN 
320 and the PCF/BS 322. The number (two) of, and identifiers for, two newly required 
PPP instances 336, 338 are advantageously included in the origination message 
transmitted by the MS 318. For simplicity, only one PCF/BS 322, 326 is shown serving 
each respective PDSN 320, 324, but it would be understood that there could be multiple 
PCF/BSs serving each PDSN 320, 324. The origination message advantageously 
includes a Data-Ready-to-Send (DRS) flag that may be set to zero to identify to the 
PDSN 324 the identity and total number of packet services that are dormant, thereby 
allowing the PDSN 324 to establish PPP instances 336, 338 and the requisite R-P links 
between the PDSN 324 and the PCF/BS 326. If a data call is in progress, the MS 318 
sets the DRS flag to one and requests reconnection or establishment of the PPP 
instance 328, 330 associated with the call. If no call is in progress, the MS 318 sets the 
DRS flag is sot to zero and reports the SRJDs for all dormant PPP service instances 
328, 330 (SRJDs 1 and 2) associated with the MS 318. The PCF/BS 326 then sends a 
message to the PDSN 324 that includes the list of SRJDs and the MSJD. The PDSN 
324 establishes two PPP instances 336, 338 and two (the number of SRJDs reported 
by the MS 318) R-P connections. The PDSN 324 and the PCF/BS 326 then update 
their respective tables 340, 342. Thus, the list of dormant SRJDs informs the PDSN 
324 how many PPP instances 336, 338 need to be initiated and also gives the PCF/BS 
326 enough information to update its R-P/SRJD table 342. 



p. 10, after line 15, insert: 

In one embodiment, as shown in FIG. 3C, an MS 366 travels from the vicinity of a 
first PDSN 354 and associated PCF/BS 362 to the vicinity of a second PDSN 356 and 
associated PCF/BS 364 and informs the second PDSN 356 of the number and identities 
of PPP instances to be established. The first PDSN 354 had established two PPP 
instances as illustrated between the PDSN 354 and the PCF/BS 362, which were 
dormant (i.e., not being used to transmit traffic channel data). The various established 
connections and addresses are included in the respective tables 350, 358 for the PDSN 
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354 and the PCF/BS 362, respectively. The number (two) of, and identifiers for, two 
newly required PPP instances 372, 374 are advantageously included in the origination 
message transmitted by the MS 366. For simplicity, only one PCF/BS 362, 364 is 
shown serving each respective PDSN 354, 356, but it would be understood that there 
could be multiple PCF/BSs serving each PDSN 354, 356. The origination message 
advantageously includes a Data-Ready-to-Send (DRS) flag that may be set to zero to 
identify to the PDSN 356 the identity and total number of packet services that are 
dormant, thereby allowing the PDSN 356 to establish PPP instances 372, 374 and the 
requisite R-P links between the PDSN 356 and the PCF/BS 364. If a data call is in 
progress, the MS 366 sets the DRS flag to one and requests reconnection or 
establishment of the PPP instance associated with the call. If no call is in progress, the 
MS 366 sets the DRS flag is set to zero and reports the SRJDs for all dormant PPP 
service instances 372, 374 (SRJDs 1 and 2) associated with the MS 366. The PCF/BS 
364 then sends a message to the PDSN 356 from the table 360 storing the R-P IDs, 
SRJDs and MSJD. The PDSN 356 establishes two PPP instances 372, 374 and two 
(the number of SRJDs reported by the MS 318) R-P connections. The PDSN 356 and 
the PCF/BS 364 then update their respective tables 352, 360. Thus, the list of dormant 
SRJDs informs the PDSN 356 how many PPP instances to initiate and also gives the 
PCF/BS 326 enough information to update its R-P/SRJD table 352. Note that the table 
352 includes the R-P IDs, MSJD, and IP address. 
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